home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-tn3270e-enhancements-00.txt < prev    next >
Text File  |  1993-07-26  |  66KB  |  1,596 lines
  1.  
  2. TN3270 Enhancements Working Group                             B. Kelly
  3. Internet Draft                                       Auburn University
  4.                                                              July 1993
  5.  
  6.  
  7.                         TN3270 Enhancements
  8.  
  9.  
  10. Status of this Memo
  11.  
  12.    This document is an Internet Draft.  Internet Drafts are working
  13.    documents of the Internet Engineering Task Force (IETF), its Areas,
  14.    and its Working Groups.  Note that other groups may also distribute
  15.    working documents as Internet Drafts.
  16.  
  17.    Internet Drafts are draft documents valid for a maximum of six
  18.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  19.    other documents at any time.  It is not appropriate to use Internet
  20.    Drafts as reference material or to cite them other than as a
  21.    "working draft" or "work in progress."
  22.  
  23.    Please check the 1id-abstracts.txt listing contained in the
  24.    internet-drafts Shadow Directories on ds.internic.net,
  25.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  26.    current status of any Internet Draft.
  27.  
  28. Abstract
  29.  
  30.    This document describes a protocol that more fully supports 3270
  31.    devices than do the existing tn3270 practices.  Specifically, it
  32.    defines a method of emulating both the terminal and printer members
  33.    of the 3270 family of devices via Telnet; it provides for the
  34.    ability of a Telnet client to request that it be assigned a
  35.    specific device-name (also referred to as "LU name" or "network
  36.    name"); finally, it adds support for a variety of functions such as
  37.    the ATTN key, the SYSREQ key, and SNA response handling.
  38.  
  39.    This protocol would be negotiated and implemented under a new
  40.    Telnet Option and would be unrelated to the Telnet 3270 Regime
  41.    Option as defined in RFC 1041 [1].
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. B. Kelly                 Expires January 1994                 [Page 1]
  59.  
  60.  
  61. Internet Draft           TN3270 Enhancements                 July 1993
  62.  
  63.  
  64. TABLE OF CONTENTS
  65.  
  66.    1.  INTRODUCTION ...............................................  2
  67.    2.  TN3270E OVERVIEW ...........................................  3
  68.    3.  COMMAND NAMES AND CODES ....................................  4
  69.    4.  COMMAND MEANINGS ...........................................  5
  70.    5.  DEFAULT SPECIFICATION ......................................  6
  71.    6.  MOTIVATION .................................................  6
  72.    7.  IMPLEMENTATION RULES .......................................  7
  73.       7.1  DEVICE-TYPE Negotiation ................................  7
  74.       7.2  FUNCTIONS Negotiation .................................. 11
  75.    8.  TN3270E DATA MESSAGES ...................................... 13
  76.       8.1  The TN3270E Message Header ............................. 13
  77.           8.1.1 DATA-TYPE Field ................................... 14
  78.           8.1.2 REQUEST-FLAG Field ................................ 14
  79.           8.1.3 RESPONSE-FLAG Field ............................... 15
  80.    9.  BASIC TN3270E .............................................. 16
  81.    10. DETAILS OF PROCESSING TN3270E FUNCTIONS .................... 17
  82.       10.1 The SCS-CTL-CODES Function ............................. 17
  83.       10.2 The DATA-STEAM-CTL Function ............................ 18
  84.       10.3 The BIND-IMAGE Function ................................ 18
  85.       10.4 The RESPONSE Function .................................. 19
  86.    11. THE 3270 ATTN KEY .......................................... 21
  87.    12. THE 3270 SYSREQ KEY ........................................ 22
  88.    13. 3270 STRUCTURED FIELDS ..................................... 23
  89.    14. EXAMPLES ................................................... 24
  90.    15. REFERENCES ................................................. 26
  91.    16. AUTHOR'S NOTE .............................................. 26
  92.    17. AUTHOR'S ADDRESS ........................................... 27
  93.  
  94.  
  95. 1.  Introduction
  96.  
  97.    Currently, support for 3270 terminal emulation over Telnet is
  98.    accomplished by the de facto standard of negotiating three separate
  99.    Telnet Options - Terminal-Type [2], Binary Transmission [3], and
  100.    End of Record [4].  Note that there is no RFC that specifies this
  101.    negotiation as a standard.  RFC 1041 attempted to standardize the
  102.    method of negotiating 3270 terminal support by defining the 3270
  103.    Regime Telnet Option.  Unfortunately, very few developers and
  104.    vendors ever implemented RFC 1041.
  105.  
  106.    This document will refer to the existing practice of negotiating
  107.    these three Telnet Options before exchanging the 3270 data stream
  108.    as "traditional tn3270".
  109.  
  110.    NOTE: Except where otherwise stated, this document does not
  111.    distinguish between Telnet servers that represent SNA devices and
  112.    those that represent non-SNA 3270 devices.
  113.  
  114.    All references in this document to the 3270 data stream, SNA versus
  115.    non-SNA operation, 3270 data stream commands, orders, structured
  116.  
  117. B. Kelly                 Expires January 1994                 [Page 2]
  118.  
  119.  
  120. Internet Draft           TN3270 Enhancements                 July 1993
  121.  
  122.  
  123.    fields and the like rely on [5].  References to SNA Request and
  124.    Response Units rely on [6].
  125.  
  126.    There are several shortcomings in traditional tn3270; among them
  127.    are the following:
  128.  
  129.     - It provides no capability for Telnet clients to emulate the 328x
  130.       class of printers.
  131.  
  132.     - There is no mechanism by which a Telnet client can request that
  133.       a connection be associated with a given 3270 device-name.  This
  134.       can be of importance when a terminal session is being
  135.       established, since many host applications behave differently
  136.       depending on the network name of the terminal.  In the case of
  137.       printer emulation, this capability is an absolute necessity
  138.       because a large number of host applications have some method of
  139.       pre-defining printer destinations.
  140.  
  141.     - The 3270 ATTN and SYSREQ keys are not universally supported.
  142.  
  143.     - There is no support for the SNA positive/negative response
  144.       process.  This is particularly important if printer emulation is
  145.       to function properly, but is also useful for some terminal
  146.       applications.  A positive response is used to indicate that
  147.       the previously received data has been successfully processed.
  148.       A negative response indicates some sort of error at the client
  149.       while processing the previously received data; this could be
  150.       caused by the host application building a 3270 data stream that
  151.       contains an invalid command, or by a mechanical error at the
  152.       client side, among other things.
  153.  
  154.     - There is no mechanism by which the client can access the SNA
  155.       BIND information.  The BIND image contains a detailed
  156.       description of the session between the Telnet server and the
  157.       host application.
  158.  
  159.     - There is no mechanism by which the server can determine whether
  160.       a client supports 3270 structured fields, or a client can
  161.       request that it receive them.
  162.  
  163.  
  164. 2.  TN3270E Overview
  165.  
  166.    In order to address these issues, this document proposes a new
  167.    Telnet Option - TN3270E (option number has yet to be assigned).
  168.    Telnet clients and servers would be free to negotiate support of
  169.    the TN3270E option or not. If either side does not support TN3270E,
  170.    traditional tn3270 can be used; otherwise, a sub-negotiation will
  171.    occur to determine what subset of TN3270E will be used on the
  172.    session.  It is anticipated that a client or server capable of both
  173.    types of 3270 emulation would attempt to negotiate TN3270E first,
  174.  
  175.  
  176. B. Kelly                 Expires January 1994                 [Page 3]
  177.  
  178.  
  179. Internet Draft           TN3270 Enhancements                 July 1993
  180.  
  181.  
  182.    and only negotiate traditional tn3270 if the other side refuses
  183.    TN3270E.
  184.  
  185.    Once a client and server have agreed to use TN3270E, negotiation of
  186.    the TN3270E suboptions can begin.  The two major elements of
  187.    TN3270E sub-negotiation are:
  188.  
  189.     - a device-type negotiation that is similar to, but somewhat
  190.       more complicated than, the existing Telnet Terminal-Type Option.
  191.  
  192.     - the negotiation of a set of supported 3270 functions, such as
  193.       printer data stream type (3270 data stream or SNA Character
  194.       Stream), positive/negative response exchanges, device status
  195.       information, and the passing of BIND information from server to
  196.       client.
  197.  
  198.    Successful negotiation of these two suboptions signals the
  199.    beginning of 3270 data stream transmission. In order to support
  200.    several of the new functions in TN3270E, each data message must be
  201.    prefixed by a header.  This header will contain flags and
  202.    indicators that convey such things as positive and negative
  203.    responses and what type of data follows the header (for example,
  204.    3270 data stream, SNA Character Stream, or device status
  205.    information).
  206.  
  207.  
  208. 3.  Command Names and Codes
  209.  
  210.        TN3270E        (to be assigned)
  211.          ASSOCIATE          00
  212.          CONNECT            01
  213.          DEVICE-TYPE        02
  214.          FUNCTIONS          03
  215.          IS                 04
  216.          REASON             05
  217.          REJECT             06
  218.          REQUEST            07
  219.          SEND               08
  220.  
  221.        Reason-codes
  222.          CONN-PARTNER       00
  223.          DEVICE-IN-USE      01
  224.          INV-ASSOCIATE      02
  225.          INV-DEVICE-NAME    03
  226.          INV-DEVICE-TYPE    04
  227.          TYPE-NAME-ERROR    05
  228.          UNKNOWN-ERROR      06
  229.          UNSUPPORTED-REQ    07
  230.  
  231.  
  232.  
  233.  
  234.  
  235. B. Kelly                 Expires January 1994                 [Page 4]
  236.  
  237.  
  238. Internet Draft           TN3270 Enhancements                 July 1993
  239.  
  240.  
  241.        Function Names
  242.          BIND-IMAGE         00
  243.          DATA-STREAM-CTL    01
  244.          RESPONSES          02
  245.          SCS-CTL-CODES      03
  246.  
  247.  
  248. 4.  Command Meanings
  249.  
  250.    IAC WILL TN3270E
  251.  
  252.       The sender of this command is willing to send TN3270E
  253.       information in subsequent sub-negotiations.
  254.  
  255.    IAC WON'T TN3270E
  256.  
  257.       The sender of this command refuses to send TN3270E information.
  258.  
  259.    IAC DO TN3270E
  260.  
  261.       The sender of this command is willing to receive TN3270E
  262.       information in subsequent sub-negotiations.
  263.  
  264.    IAC DON'T TN3270E
  265.  
  266.       The sender of this command refuses to receive TN3270E
  267.       information.
  268.  
  269.    Note that while they are not explicitly negotiated, the equivalent
  270.    of the Telnet Binary Transmission Option [3] and the Telnet End of
  271.    Record Option [4] is implied in the negotiation of the TN3270E
  272.    Option.  That is, a party to the negotiation that agrees to support
  273.    TN3270E is automatically required to support bi-directional binary
  274.    and EOR transmissions.
  275.  
  276.    IAC SB TN3270E SEND DEVICE-TYPE IAC SE
  277.  
  278.       Only the server may send this command.  This command is used to
  279.       request that the client transmit a device-type and, optionally,
  280.       device-name information.
  281.  
  282.    IAC SB TN3270E DEVICE-TYPE REQUEST <device-type>
  283.           [CONNECT | ASSOCIATE <device-name>] IAC SE
  284.  
  285.       Only the client may send this command.  It is used in response
  286.       to the server's SEND DEVICE-TYPE command, as well as to suggest
  287.       another device-type after the server has sent a DEVICE-TYPE
  288.       REJECT command (see below).  This command requests emulation of
  289.       a specific 3270 device type and model.  The REQUEST command may
  290.       optionally include either the CONNECT or the ASSOCIATE command
  291.       (but not both).  If present, CONNECT and ASSOCIATE must both be
  292.  
  293.  
  294. B. Kelly                 Expires January 1994                 [Page 5]
  295.  
  296.  
  297. Internet Draft           TN3270 Enhancements                 July 1993
  298.  
  299.  
  300.       followed by <device-name>.  (See the section entitled
  301.       "Implementation Rules" for more detailed information.)
  302.  
  303.    IAC SB TN3270E DEVICE-TYPE IS <device-type> CONNECT
  304.           <device-name> IAC SE
  305.  
  306.       Only the server may send this command.  This command is used to
  307.       accept a client's DEVICE-TYPE REQUEST command.
  308.  
  309.    IAC SB TN3270E DEVICE-TYPE REJECT REASON <reason-code> IAC SE
  310.  
  311.       Only the server may send this command.  This command is used to
  312.       reject a client's DEVICE-TYPE REQUEST command.
  313.  
  314.    IAC SB TN3270E FUNCTIONS REQUEST <function-list> IAC SE
  315.  
  316.       Either side may send this command.  This command is used to
  317.       suggest a set of 3270 functions that will be supported on this
  318.       session.  It is also sent as an implicit rejection of a previous
  319.       FUNCTIONS REQUEST command sent by the other side (see the
  320.       section entitled "Implementation Rules" for more information).
  321.       Note that when used to reject a FUNCTIONS REQUEST command, the
  322.       function-list must not be identical to that received in the
  323.       previous REQUEST command.
  324.  
  325.    IAC SB TN3270E FUNCTIONS IS <function-list> IAC SE
  326.  
  327.       Either side may send this command.  This command is sent as a
  328.       response to a FUNCTIONS REQUEST command and implies acceptance
  329.       of the set of functions sent to it in the REQUEST command.  Note
  330.       that the list of functions in the FUNCTIONS IS command must
  331.       match the list that was received in the previous FUNCTIONS
  332.       REQUEST command.
  333.  
  334.  
  335. 5.  Default Specification
  336.  
  337.    WON'T TN3270E
  338.  
  339.    DON'T TN3270E
  340.  
  341.    i.e., TN3270E will not be used.
  342.  
  343.  
  344. 6.  Motivation
  345.  
  346.    See the section entitled "Introduction."
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353. B. Kelly                 Expires January 1994                 [Page 6]
  354.  
  355.  
  356. Internet Draft           TN3270 Enhancements                 July 1993
  357.  
  358.  
  359. 7.  Implementation Rules
  360.  
  361.    All TN3270E commands and parameters are NVT ASCII strings in which
  362.    upper and lower case are considered equivalent.
  363.  
  364.    Once it has been agreed that TN3270E will be supported, the first
  365.    sub-negotiation must concern the DEVICE-TYPE (and possibly
  366.    DEVICE-NAME) information.  Only after that has been successfully
  367.    negotiated can the client and server exchange FUNCTIONS
  368.    information.  Only after both DEVICE-TYPE and FUNCTIONS have been
  369.    successfully negotiated can 3270 data stream transmission occur.
  370.  
  371.    7.1 DEVICE-TYPE Negotiation
  372.  
  373.       Device-type (and device-name) negotiation begins when the server
  374.       transmits the DEVICE-TYPE SEND command to the client.  The
  375.       client responds with the DEVICE-TYPE REQUEST command, which must
  376.       include a device-type and may include a device-name request.
  377.  
  378.       Valid device-types are:
  379.  
  380.         terminals: IBM-3278-2-E
  381.                    IBM-3278-3-E
  382.                    IBM-3278-4-E
  383.                    IBM-3278-5-E
  384.                    IBM-3279-2-E
  385.                    IBM-3279-3-E
  386.  
  387.          printers: IBM-3287-1
  388.  
  389.       An explanation of the CONNECT and ASSOCIATE commands first
  390.       requires a discussion of the organization of terminal and
  391.       printer device pools that the server maintains and from which it
  392.       selects device-names to assign to session requests.  (The terms
  393.       "device-name", "LU name" and "network name" can be considered
  394.       interchangeable in this document.)  Also, for the purposes of
  395.       this discussion, the term "generic session request" will be used
  396.       to describe a request for a session from a Telnet client (either
  397.       traditional or TN3270E) that does not include a request for a
  398.       specific device-name.  The term "specific session request" will
  399.       be used to describe a request for a session from a TN3270E
  400.       client that includes a request for a specific device-name
  401.       (either via CONNECT or ASSOCIATE).
  402.  
  403.       As is the case with traditional tn3270, the TN3270E server must
  404.       maintain a set of terminal device-names.  A generic request for
  405.       a terminal session would result in the server selecting any
  406.       availabe device-name from this pool.  The server, however, may
  407.       also maintain a separate pool of terminal device-names which can
  408.       only be used to satisfy specific terminal session requests.
  409.       This is to ensure that a terminal device that has some
  410.  
  411.  
  412. B. Kelly                 Expires January 1994                 [Page 7]
  413.  
  414.  
  415. Internet Draft           TN3270 Enhancements                 July 1993
  416.  
  417.  
  418.       significance to host applications (and is therefore likely to be
  419.       the target of a specific session request) is not "accidentally"
  420.       assigned to a generic request and winds up associated with a
  421.       client that has no use for it.  Note that the reverse situation
  422.       is allowed.  That is, a specific terminal session request could
  423.       ask for a device-name that happens to be in the "generic
  424.       terminal pool."
  425.  
  426.       For each terminal device (in both the "generic" and the
  427.       "specific" pools), the TN3270E server could also have defined a
  428.       "partner" or "paired" printer device.  There should be a unique,
  429.       one-to-one mapping between a terminal and its associated
  430.       printer.  The reasoning behind such a configuration is to allow
  431.       for those host applications that produce printed output bound
  432.       for a printer whose device-name is determined by the device-name
  433.       of the terminal that initiated the print request.  These printer
  434.       devices can only be assigned to specific printer session
  435.       requests that use the ASSOCIATE command (see below).
  436.  
  437.       In addition, the TN3270E server may also maintain a pool of
  438.       printer device-names that are not associated with any terminal.
  439.       These printer devices can only be assigned to specific printer
  440.       session requests that use the CONNECT command (see below).  This
  441.       allows for those host applications that generate printed output
  442.       bound for a printer whose device-name is determined by something
  443.       other than the device-name of the terminal that initiated the
  444.       print request (for example, when the userid of the person signed
  445.       on to a terminal determines the print destination).
  446.  
  447.       Finally, it is possible that a pool of printer device-names
  448.       could be maintained and used only to satisfy generic requests
  449.       for printers.
  450.  
  451.       CONNECT is used by the client to request that the server assign
  452.       a specific device-name to this Telnet session; it may be used
  453.       when requesting either a terminal or a printer session.  The
  454.       specified device-name must not conflict with the device-type;
  455.       e.g., if the client requests DEVICE-TYPE IBM-3287-1 (a printer)
  456.       and specifies CONNECT T1000001, but T1000001 is defined at the
  457.       host as a terminal, then the server should deny the request.
  458.       Further, if the requested device-name is already associated with
  459.       some other Telnet session, or if it is not defined to the
  460.       server, the server should deny the request.
  461.  
  462.       ASSOCIATE can be used by the client only when requesting a
  463.       DEVICE-TYPE that represents a printer. The ASSOCIATE command
  464.       requests that this session be assigned the device-name of the
  465.       printer that is paired with the terminal named in the request.
  466.       If the device-type does not represent a printer, or if the
  467.       device-name is not that of a terminal, then the server should
  468.       deny the request.  It is anticipated that the device-name
  469.  
  470.  
  471. B. Kelly                 Expires January 1994                 [Page 8]
  472.  
  473.  
  474. Internet Draft           TN3270 Enhancements                 July 1993
  475.  
  476.  
  477.       specified in this request would be one returned by the server
  478.       when accepting a previous terminal session request (see the IS
  479.       command below).  Since no means of authentication has been
  480.       provided for, it is possible that the printer paired with the
  481.       terminal specified in the ASSOCIATE command has already been
  482.       assigned to some other Telnet session; in this case, the server
  483.       should deny the request.
  484.  
  485.       To summarize, assume a TN3270E server has the following device
  486.       pools defined to it (device-names that begin with a "T" are
  487.       terminal devices; those that begin with a "P" are printers):
  488.  
  489.        Generic Terminal Pool              Specific Terminal Pool
  490.        ---------------------              ----------------------
  491.        TG000001 <--> PTG00001             TS000001 <--> PTS00001
  492.        TG000002 <--> PTG00002             TS000001 <--> PTS00002
  493.        TG000003 <--> PTG00003             TS000001 <--> PTS00003
  494.  
  495.        Generic Printer Pool               Specific Printer Pool
  496.        --------------------               ----------------------
  497.             PG000001                            PS000001
  498.             PG000002                            PS000002
  499.             PG000003                            PS000003
  500.  
  501.       Note that the only pool that absolutely must be defined to the
  502.       server is the generic terminal pool.  The absence of other pools
  503.       (or of partner printers for a terminal pool) simply means that
  504.       the server is unable to satisfy as wide a variety of requests as
  505.       would be possible if all pools were defined to it.
  506.  
  507.       Given the above configuration, the following rules apply:
  508.  
  509.       - a generic terminal request can only be satisfied from the
  510.         generic terminal pool (device-names TG000001 - TG000003).
  511.  
  512.       - a specific terminal request (allowable only via the CONNECT
  513.         command) can be satisfied from either the generic or the
  514.         specific terminal pool, although it is anticipated that the
  515.         majority of such requests would ask for terminals in the
  516.         specific terminal pool (TS000001 - TS000003).
  517.  
  518.       - a generic printer request can only be satisfied from the
  519.         generic printer pool (device-names PG000001 - PG000003).
  520.  
  521.       - a specific printer request may come in one of two forms:
  522.  
  523.         via ASSOCIATE: the request can only be satisfied using the
  524.                        partner of the specified terminal, which
  525.                        may be in the generic or the specific
  526.                        terminal pool; therefore, devices in the
  527.  
  528.  
  529.  
  530. B. Kelly                 Expires January 1994                 [Page 9]
  531.  
  532.  
  533. Internet Draft           TN3270 Enhancements                 July 1993
  534.  
  535.  
  536.                        ranges PTG00001 - PTG00003 and PTS00001 -
  537.                        PTS00003 can be used to satisfy the request.
  538.  
  539.         via CONNECT:   the request can be satisfied either from
  540.                        the generic or the specific printer pools
  541.                        (although, as with specific terminal requests,
  542.                        it is likely that most such requests will name
  543.                        printers in the specific printer pool); this
  544.                        request cannot be satisfied with the partner
  545.                        printer of a terminal in either the specific or
  546.                        the generic terminal pools.
  547.  
  548.       The server must accept the client's request or deny it as a
  549.       whole - it cannot, for example, accept the DEVICE-TYPE request
  550.       but deny the CONNECT portion.
  551.  
  552.       If the server wishes to accept the request, it sends back the
  553.       DEVICE-TYPE IS command confirming the requested device-type and
  554.       the CONNECT command specifying the device-name of the terminal
  555.       or printer assigned to this Telnet session.  This device-name
  556.       may be the one directly requested (via CONNECT) by the client,
  557.       the one indirectly requested (via ASSOCIATE) by the client, or
  558.       one chosen by the server if the client specified neither CONNECT
  559.       nor ASSOCIATE.
  560.  
  561.       If the server wishes to deny the request, it sends back the
  562.       DEVICE-TYPE REJECT command with one of the following
  563.       reason-codes:
  564.  
  565.          Reason code name         Explanation
  566.          ----------------         -----------------------------------
  567.          INV-DEVICE-TYPE          The server does not support the
  568.                                   requested device-type.
  569.  
  570.          INV-DEVICE-NAME          The device-name specified in the
  571.                                   CONNECT or ASSOCIATE command is
  572.                                   not known to the server.
  573.  
  574.          DEVICE-IN-USE            The requested device-name is
  575.                                   already associated with another
  576.                                   Telnet session.
  577.  
  578.          TYPE-NAME-ERROR          The requested device-name is
  579.                                   incompatible with the requested
  580.                                   device-type (such as terminal/
  581.                                   printer mismatch).
  582.  
  583.          UNSUPPORTED-REQ          The server is unable to satisfy
  584.                                   the type of request sent by the
  585.                                   client; e.g., a specific terminal
  586.                                   or printer was requested but the
  587.  
  588.  
  589. B. Kelly                 Expires January 1994                [Page 10]
  590.  
  591.  
  592. Internet Draft           TN3270 Enhancements                 July 1993
  593.  
  594.  
  595.                                   server does not have such a pool of
  596.                                   device-names defined to it, or the
  597.                                   ASSOCIATE command was used but no
  598.                                   partner printers are defined to the
  599.                                   server.
  600.  
  601.          INV-ASSOCIATE            The client used the ASSOCIATE
  602.                                   command and either the device-type
  603.                                   is not a printer or the device-name
  604.                                   is not a terminal.
  605.  
  606.          CONN-PARTNER             The client used the CONNECT command
  607.                                   to request a specific printer but
  608.                                   the device-name requested is the
  609.                                   partner to some terminal.
  610.  
  611.          UNKNOWN-ERROR            Any other error in device type or
  612.                                   name processing has occurred.
  613.  
  614.       The process of negotiating a device-type and device-name that
  615.       are acceptable to both client and server may entail several
  616.       iterations of DEVICE-TYPE REQUEST and DEVICE-TYPE REJECT
  617.       commands.  The client should make use of the reason-code
  618.       specified by the server in any DEVICE-TYPE REJECT command(s) to
  619.       minimize the amount of negotiation necessary.  For example, if
  620.       the client initially requests that it be assigned a specific
  621.       terminal device-name via the CONNECT command, and the server
  622.       rejects the request with a reason-code of UNSUPPORTED-REQ, the
  623.       client should make no further specific terminal requests in the
  624.       negotiations.  If at any point in the process either side wishes
  625.       to "bail out," it can simply send a WON'T (or DON'T) TN3270E
  626.       command to the other side.  At this point both sides are free to
  627.       negotiate other Telnet options (including traditional tn3270).
  628.  
  629.  
  630.    7.2 FUNCTIONS Negotiation
  631.  
  632.       Once the DEVICE-TYPE negotiation has successfully completed
  633.       (i.e, when the client receives the DEVICE-TYPE IS command), the
  634.       client should initiate the FUNCTIONS negotiation by sending the
  635.       FUNCTIONS REQUEST command to the server.  After this initial
  636.       REQUEST command, both sides are free to transmit FUNCTIONS
  637.       REQUEST and FUNCTIONS IS commands as needed.
  638.  
  639.       The FUNCTIONS REQUEST command contains a list of the 3270
  640.       functions that the sender would like to see supported on this
  641.       session.  All functions not in the list are to be considered
  642.       unsupported.  The function-list consists of a string of 2-byte
  643.       entries separated from one another by a single space character.
  644.       The list is terminated by the IAC code that precedes the SE
  645.       command.  Functions may appear in any order in the list.
  646.  
  647.  
  648. B. Kelly                 Expires January 1994                [Page 11]
  649.  
  650.  
  651. Internet Draft           TN3270 Enhancements                 July 1993
  652.  
  653.  
  654.       Upon receipt of a FUNCTIONS REQUEST command, the recipient has
  655.       two choices:
  656.  
  657.        - it may respond in the positive (meaning it agrees to support
  658.          all functions in the list, and not to transmit any data
  659.          related to functions not in the list).  To do this, it sends
  660.          the FUNCTIONS IS command with the function-list exactly as it
  661.          was received.  At this point, FUNCTIONS negotiation has
  662.          successfully completed.
  663.  
  664.        - it may respond in the negative by sending a FUNCTIONS
  665.          REQUEST command in which the function-list differs from the
  666.          one it received (and not simply in the order of appearance
  667.          of functions in the list; at least one function must have
  668.          been added to, or removed from, the list).
  669.  
  670.       To avoid endlessly looping, neither party should add to the
  671.       function-list it receives any function that it has previously
  672.       added and that the other side has removed.
  673.  
  674.       The process of sending FUNCTIONS REQUEST commands back and forth
  675.       continues until one side receives a function-list it is willing
  676.       to live with.  It uses the FUNCTIONS IS command to accept the
  677.       list, and, once this command is received by the other side, all
  678.       necessary negotiation has been completed.  At this point, 3270
  679.       data stream transmission can begin.
  680.  
  681.       Note that it is possible that the function-list agreed to is
  682.       null; this is referred to as "basic TN3270E."  See the section
  683.       entitled "Basic TN3270E" for more information.
  684.  
  685.       The following list briefly describes the 3270 functions that may
  686.       be negotiated in the function-list:
  687.  
  688.           Function Name       Description
  689.           -------------       -----------
  690.          SCS-CTL-CODES       (Printer sessions only).  Allows the use
  691.                              of the SNA Character Stream (SCS) and SCS
  692.                              control codes on the session.  SCS is
  693.                              used with LU type 1 SNA sessions.
  694.  
  695.          DATA-STREAM-CTL     (Printer sessions only).  Allows the use
  696.                              of the standard 3270 data stream. This
  697.                              corresponds to LU type 3 SNA sessions.
  698.                              DATA-STREAM-CTL is mutually exclusive
  699.                              with SCS-CTL-CODES (only one of these
  700.                              should appear in a function-list).
  701.  
  702.          RESPONSES           Provides support for positive and
  703.                              negative response handling.  Allows the
  704.  
  705.  
  706.  
  707. B. Kelly                 Expires January 1994                [Page 12]
  708.  
  709.  
  710. Internet Draft           TN3270 Enhancements                 July 1993
  711.  
  712.  
  713.                              server to reflect to the client any and
  714.                              all definite, exception, and no response
  715.                              requests sent by the host application.
  716.  
  717.          BIND-IMAGE          Allows the server to send (upon request)
  718.                              the SNA BIND image to the client.
  719.  
  720.       See the section entitled "Details of Processing TN3270E
  721.       Functions" for a more detailed explanation of the meaning and
  722.       use of these functions.
  723.  
  724.  
  725. 8.  TN3270E Data Messages
  726.  
  727.    3270 device communications are generally understood to be block
  728.    oriented in nature.  That is, each partner buffers data until an
  729.    entire "message" has been built, at which point the data is sent to
  730.    the other side.  The "message" consists of a series of 3270
  731.    commands, buffer orders, buffer addresses, and data.  The end of a
  732.    message is understood to be the last byte transmitted (note that
  733.    this discussion disregards SNA chaining).  The Telnet EOR command
  734.    is used to delimit these natural 3270 blocks of data within the
  735.    Telnet data stream.
  736.  
  737.    In TN3270E, each 3270 message must be prefixed with a TN3270E
  738.    header, which consists of four bytes and whose format is defined
  739.    below (see the section entitled "The TN3270E Message Header").
  740.  
  741.    A "data message" in TN3270E therefore has the following
  742.    construction:
  743.  
  744.           <TN3270E Header><data><IAC EOR>
  745.  
  746.    It should be noted that it is possible that, for certain message
  747.    types, there is no data portion present.  In this case, the TN3270E
  748.    data message consists of:
  749.  
  750.           <TN3270E Header><IAC EOR>
  751.  
  752.    Note also that Telnet commands may appear anywhere in the Telnet
  753.    stream.  For this reason, if either side wishes to transmit the
  754.    decimal value 255 and have it interpreted as data, it must "double"
  755.    this byte.  In other words, a single occurance of decimal 255 will
  756.    be interpreted by the other side as an IAC, while two successive
  757.    bytes containing decimal 255 will be treated as one data byte with
  758.    a value of decimal 255.
  759.  
  760.  
  761.    8.1 The TN3270E Message Header
  762.  
  763.       As stated earlier, each data message in TN3270E must be prefixed
  764.  
  765.  
  766. B. Kelly                 Expires January 1994                [Page 13]
  767.  
  768.  
  769. Internet Draft           TN3270 Enhancements                 July 1993
  770.  
  771.  
  772.       by a header, which consists of four bytes and is formatted as
  773.       follows:
  774.  
  775.           ------------------------------------------------
  776.           |   DATA-TYPE   | REQUEST-FLAG | RESPONSE-FLAG |
  777.           ------------------------------------------------
  778.                2 bytes         1 byte         1 byte
  779.  
  780.  
  781.      8.1.1 DATA-TYPE Field
  782.  
  783.       The DATA-TYPE field indicates how the data portion of the
  784.       message is to be interpreted by the receiver.  Possible values
  785.       for the DATA-TYPE field are:
  786.  
  787.         Data-type Name   Code                Meaning
  788.         --------------   ----   ---------------------------------
  789.         3270-DATA         00    The data portion of the message
  790.                                 contains only the 3270 data stream.
  791.  
  792.         SCS-DATA          01    The data portion of the message
  793.                                 contains SNA Character Stream data.
  794.  
  795.         RESPONSE          02    The data portion of the message
  796.                                 constitutes device-status information
  797.                                 and the RESPONSE-FLAG field indicates
  798.                                 whether this is a postive or negative
  799.                                 response (see below).
  800.  
  801.         BIND-IMAGE        03    The data portion of the message is
  802.                                 the SNA bind image from the session
  803.                                 established between the server and the
  804.                                 host application.
  805.  
  806.         NVT-DATA          04    The data portion of the message is to
  807.                                 be interpreted as NVT data.
  808.  
  809.         REQUEST           05    There is no data portion present in
  810.                                 the message.  Only the REQUEST-FLAG
  811.                                 field has any meaning.
  812.  
  813.  
  814.      8.1.2 REQUEST-FLAG Field
  815.  
  816.       The REQUEST-FLAG field only has meaning when the DATA-TYPE field
  817.       has a value of REQUEST; otherwise, the REQUEST-FLAG field must
  818.       be ignored by the receiver and should be set to 0x00 by the
  819.       sender.  Possible values for the REQUEST-FLAG field are:
  820.  
  821.  
  822.  
  823.  
  824.  
  825. B. Kelly                 Expires January 1994                [Page 14]
  826.  
  827.  
  828. Internet Draft           TN3270 Enhancements                 July 1993
  829.  
  830.  
  831.         Request-Flag Name   Code                Meaning
  832.         -----------------   ----   ---------------------------------
  833.         SEND-BIND             0    The client wishes the server to
  834.                                    send a copy of the SNA bind image
  835.                                    used to establish a session between
  836.                                    the host application and the
  837.                                    server.
  838.  
  839.         BIND-UNAVAILABLE      1    The server sends this to the client
  840.                                    if it has received a SEND-BIND
  841.                                    request from the client, but there
  842.                                    is no bind image to send.
  843.  
  844.         ERR-COND-CLEARED      2    The client sends this to the server
  845.                                    when some previously encountered
  846.                                    printer error condition has been
  847.                                    cleared.  (See the section entitled
  848.                                    "The RESPONSE Function" below.)
  849.  
  850.  
  851.      8.1.3 RESPONSE-FLAG Field
  852.  
  853.       The RESPONSE-FLAG field only has meaning for certain values of
  854.       the DATA-TYPE field.  For DATA-TYPE field values of 3270-DATA
  855.       and SCS-DATA, the RESPONSE-FLAG is an indication of whether or
  856.       not the sender of the data expects to receive a response.  In
  857.       this case the possible values of RESPONSE-FLAG are:
  858.  
  859.         Response-Flag Name  Code                Meaning
  860.         ------------------  ----   ---------------------------------
  861.         NO-RESPONSE           0    The sender does not expect the
  862.                                    receiver to respond either
  863.                                    positively or negatively to this
  864.                                    message.
  865.  
  866.         ERROR-RESPONSE        1    The sender only expects the
  867.                                    receiver to respond to this message
  868.                                    if some type of error occurred, in
  869.                                    which case a negative response is
  870.                                    expected.
  871.  
  872.         ALWAYS-RESPONSE       2    The sender expects the receiver to
  873.                                    respond negatively if an error
  874.                                    occurs, or positively if no errors
  875.                                    occur.
  876.  
  877.       For a DATA-TYPE field value of RESPONSE, the RESPONSE-FLAG is an
  878.       actual response to the previous data message (which must by
  879.       definition have had a DATA-TYPE of either 3270-DATA or SCS-DATA
  880.       and a RESPONSE-FLAG value of either ERROR-RESPONSE or
  881.       ALWAYS-RESPONSE).  In this case the possible values of
  882.       RESPONSE-FLAG are:
  883.  
  884. B. Kelly                 Expires January 1994                [Page 15]
  885.  
  886.  
  887. Internet Draft           TN3270 Enhancements                 July 1993
  888.  
  889.  
  890.         Response-Flag Name  Code                Meaning
  891.         ------------------  ----   ---------------------------------
  892.         POSITIVE-RESPONSE     0    The previous message was received
  893.                                    and executed successfully with
  894.                                    no errors.
  895.  
  896.         NEGATIVE-RESPONSE     1    The previous message was received
  897.                                    but an error(s) occurred while
  898.                                    processing it.
  899.  
  900.       Accompanying device status information will be found in the data
  901.       portion of the message.
  902.  
  903.       For any other values of the DATA-TYPE field, the RESPONSE-FLAG
  904.       field must be ignored by the receiver and should be set to 0x00
  905.       by the sender.
  906.  
  907.  
  908. 9. Basic TN3270E
  909.  
  910.    As has been stated earlier, whether or not the use of each of the
  911.    TN3270E functions is allowed on a session is negotiated when the
  912.    connection is established.  It is possible that none of the
  913.    functions are agreed to (in this case, the function-list in the
  914.    FUNCTIONS REQUEST and FUNCTIONS IS commands is null).  This
  915.    mode of operation is referred to as "basic TN3270E."  Note that,
  916.    since neither SCS-CTL-CODES nor DATA-STREAM-CTL is negotiated,
  917.    basic TN3270E refers to terminal sessions only.
  918.  
  919.    Basic TN3270E requires the support of only the following TN3270E
  920.    header values:
  921.  
  922.           Header field         Value
  923.           ------------         -----
  924.            DATA-TYPE          3270-DATA
  925.            DATA-TYPE          SCS-DATA
  926.            DATA-TYPE          NVT-DATA
  927.  
  928.    At any given time, a TN3270E connection can be considered to be
  929.    operating in either "3270 mode" or "NVT mode."  In 3270 mode, each
  930.    party may send data messages with the DATA-TYPE flag set to either
  931.    3270-DATA or SCS-DATA (SCS-DATA is used only in support of the
  932.    SYSREQ key); sending a DATA-TYPE flag set to NVT-DATA constitutes a
  933.    request to switch modes.  In NVT mode, each party may send data
  934.    messages with the DATA-TYPE flag set to NVT-DATA; sending 3270-DATA
  935.    or SCS-DATA is a request to switch modes.  The connection is
  936.    initially in 3270 mode when TN3270E operation is successfully
  937.    negotiated.  When a party receives a message with a DATA-TYPE
  938.    different from the mode it is operating in, the mode of operation
  939.    for the connection is switched.  Switching modes results in the
  940.    client performing the equivalent of a 3270 Erase/Reset operation,
  941.    as described in [5], using the default partition size.  The server
  942.  
  943. B. Kelly                 Expires January 1994                [Page 16]
  944.  
  945.  
  946. Internet Draft           TN3270 Enhancements                 July 1993
  947.  
  948.  
  949.    cannot assume the client preserves any attributes of the previous
  950.    environment across a mode switch.
  951.  
  952.    Typically, NVT data is used by a server to interact with the user
  953.    of a client.  It allows the server to do this using a simple NVT
  954.    data stream, instead of requiring a 3270 data stream.  An example
  955.    would be a server which displays a list of 3270 applications to
  956.    which it can connect the client.  The server would use NVT data to
  957.    display the list and read the user's choice.  Then the server would
  958.    connect to the application, and begin the exchange of 3270 data
  959.    between the application and the client.
  960.  
  961.    The REQUEST-FLAG and RESPONSE-FLAG fields are not used in basic
  962.    TN3270E.
  963.  
  964.  
  965. 10. Details of Processing TN3270E Functions
  966.  
  967.    Agreement by both parties to a specific function in the FUNCTIONS
  968.    REQUEST function-list implies agreement by each party to support a
  969.    related set of values in the TN3270E header.  It also implies a
  970.    willingness to adhere to the rules governing the processing of data
  971.    messages as regards the agreed upon function.  Either party that
  972.    fails to accept header values associated either with agreed upon
  973.    functions or with basic TN3270E, or attempts to use header values
  974.    associated with a function that is not a part of basic TN3270E and
  975.    was not agreed upon, will be considered non-conforming and in
  976.    violation of the protocol.  The following sections detail for each
  977.    TN3270E function the associated header values and processing
  978.    rules.
  979.  
  980.  
  981.    10.1 The SCS-CTL-CODES Function
  982.  
  983.       This function can only be supported on a 3270 printer session.
  984.       If either party receives this function in a FUNCTIONS REQUEST
  985.       function-list when the previously negotiated device-type
  986.       represents a terminal, it must remove the SCS-CTL-CODES function
  987.       from the list before responding with a FUNCTIONS REQUEST of its
  988.       own.  Either SCS-CTL-CODES or DATA-STREAM-CTL must be agreed to
  989.       by both parties when the negotiated device-type represents a
  990.       printer.
  991.  
  992.       Agreement to support this function requires that the party
  993.       support the following TN3270E header values:
  994.  
  995.           Header field         Value
  996.           ------------         -----
  997.            DATA-TYPE          SCS-DATA
  998.  
  999.       When SCS-CTL-CODES is in effect, neither side should send a data
  1000.       message with a DATA-TYPE of 3270-DATA.
  1001.  
  1002. B. Kelly                 Expires January 1994                [Page 17]
  1003.  
  1004.  
  1005. Internet Draft           TN3270 Enhancements                 July 1993
  1006.  
  1007.  
  1008.    10.2 The DATA-STREAM-CTL Function
  1009.  
  1010.       This function can only be supported on a 3270 printer session.
  1011.       If either party receives this function in a FUNCTIONS REQUEST
  1012.       function-list when the previously negotiated device-type
  1013.       represents a terminal, it must remove the DATA-STREAM-CTL
  1014.       function from the list before responding with a FUNCTIONS
  1015.       REQUEST of its own.
  1016.  
  1017.       Agreement to support this function requires that the party
  1018.       support the following TN3270E header values:
  1019.  
  1020.           Header field         Value
  1021.           ------------         -----
  1022.            DATA-TYPE          3270-DATA
  1023.  
  1024.       When DATA-STREAM-CTL is in effect, neither side should send a
  1025.       data message with a DATA-TYPE of SCS-DATA.
  1026.  
  1027.  
  1028.    10.3 The BIND-IMAGE Function
  1029.  
  1030.       This function can only be supported when the TN3270E server
  1031.       represents SNA terminals and printers.
  1032.  
  1033.       Agreement to support this function requires that the party
  1034.       support the following TN3270E header values:
  1035.  
  1036.           Header field         Value
  1037.           ------------         -----
  1038.            DATA-TYPE          BIND-IMAGE
  1039.            DATA-TYPE          REQUEST
  1040.            REQUEST-FLAG       SEND-BIND
  1041.            REQUEST-FLAG       BIND-UNAVAILABLE
  1042.  
  1043.       At any point after support of the BIND-IMAGE function has been
  1044.       agreed upon, the client may send a data message to the server in
  1045.       which the header DATA-TYPE field is set to REQUEST, and the
  1046.       header REQUEST-FLAG is set to SEND-BIND.  There is no data
  1047.       portion in this message.  If an SNA session exists between the
  1048.       server and a host application on behalf of the client, the
  1049.       server must respond with a data message in which the header
  1050.       DATA-TYPE field is set to BIND-IMAGE and the data portion of the
  1051.       message consists solely of the exact image of the SNA bind that
  1052.       was used to establish that SNA session.  If the server has no
  1053.       session established with a host application on behalf of the
  1054.       client when it receives the SEND-BIND request, it should send a
  1055.       data message to the client in which the header DATA-TYPE field
  1056.       is set to REQUEST and the header REQUEST-FLAG is set to
  1057.       BIND-UNAVAILABLE.
  1058.  
  1059.  
  1060.  
  1061. B. Kelly                 Expires January 1994                [Page 18]
  1062.  
  1063.  
  1064. Internet Draft           TN3270 Enhancements                 July 1993
  1065.  
  1066.  
  1067.    10.4 The RESPONSE Function
  1068.  
  1069.       This function can be supported for both terminal and printer
  1070.       sessions connected to both SNA and non-SNA servers.
  1071.  
  1072.       Agreement to support this function requires that the party
  1073.       support the following TN3270E header values:
  1074.  
  1075.           Header field         Value
  1076.           ------------         -----
  1077.            DATA-TYPE          RESPONSE
  1078.            DATA-TYPE          REQUEST
  1079.            RESPONSE-FLAG      -all values-
  1080.            REQUEST-FLAG       ERR-COND-CLEARED
  1081.  
  1082.       When the RESPONSE function is in effect, each party must adhere
  1083.       to the following rules:
  1084.  
  1085.        - Whenever a data message is sent with a DATA-TYPE of either
  1086.          SCS-DATA or 3270-DATA, the sender must set the RESPONSE-FLAG
  1087.          field to either NO-RESPONSE, ERROR-RESPONSE, or
  1088.          ALWAYS-RESPONSE.  It is anticipated that the client side will
  1089.          normally set RESPONSE-FLAG to NO-RESPONSE.  The server, if it
  1090.          represents an SNA device, should set RESPONSE-FLAG to reflect
  1091.          the response value set in the RH of the RU that generated
  1092.          this data message - Definite Response resulting in a
  1093.          RESPONSE-FLAG value of ALWAYS-RESPONSE, Exception Response
  1094.          resulting in ERROR-RESPONSE being set, and No Response
  1095.          causing a setting of NO-RESPONSE.  A non-SNA server should
  1096.          set RESPONSE-FLAG to ERROR-RESPONSE.
  1097.  
  1098.        - Whenever a data message with a DATA-TYPE of either SCS-DATA
  1099.          or 3270-DATA is received, the receiver must attempt to
  1100.          process the data in the data portion of the message, then
  1101.          determine whether or not it should send a data message with a
  1102.          DATA-TYPE of RESPONSE.  If the data message it has just
  1103.          processed had a RESPONSE-FLAG value of NO-RESPONSE, or if it
  1104.          had a value of ERROR-RESPONSE and there were no errors
  1105.          encountered while processing the data, then no RESPONSE type
  1106.          message should be sent.  Otherwise, a data message should be
  1107.          sent in which the header DATA-TYPE field is set to RESPONSE.
  1108.          The RESPONSE-FLAG field in this header must have a value of
  1109.          either POSITIVE-RESPONSE or NEGATIVE-RESPONSE.  A
  1110.          POSITIVE-RESPONSE should be sent if the previously processed
  1111.          message's header specified ALWAYS-RESPONSE and no errors
  1112.          were encountered in processing the data.  A NEGATIVE-RESPONSE
  1113.          should be sent when
  1114.  
  1115.           1) the previously processed message specified ERROR-RESPONSE
  1116.              or ALWAYS-RESPONSE and
  1117.  
  1118.  
  1119.  
  1120. B. Kelly                 Expires January 1994                [Page 19]
  1121.  
  1122.  
  1123. Internet Draft           TN3270 Enhancements                 July 1993
  1124.  
  1125.  
  1126.           2) some kind of error occurred while processing the data.
  1127.  
  1128.          Please keep in mind that it is normally only the client that
  1129.          will be constructing and sending these RESPONSE messages.  A
  1130.          negative response sent by the client to the server is the
  1131.          equivalent of a Unit Check Status [7].  All references to
  1132.          device status and sense codes in this section rely on [7].
  1133.  
  1134.          The data portion of this RESPONSE message must consist of one
  1135.          byte of binary data.  The value of this byte gives a more
  1136.          detailed account of the results of having processed the
  1137.          previously received data message.  The possible values for
  1138.          this byte are:
  1139.  
  1140.            For a RESPONSE-FLAG value of POSITIVE-RESPONSE -
  1141.  
  1142.              Value            Meaning
  1143.              -----            -------
  1144.              0x00      Successful completion (when sent by the client,
  1145.                        this is equivalent to "Device End").
  1146.  
  1147.            For a RESPONSE-FLAG value of NEGATIVE-RESPONSE -
  1148.  
  1149.              Value            Meaning
  1150.              -----            -------
  1151.              0x00      An invalid 3270 command was received
  1152.                        (equivalent to "Command Reject").
  1153.  
  1154.              0x01      Printer is not ready (equivalent to
  1155.                        "Intervention Required").
  1156.  
  1157.              0x02      An illegal 3270 buffer address or order
  1158.                        sequence was received (equivalent to
  1159.                        "Operation Check").
  1160.  
  1161.              0x03      Printer is powered off or not connected
  1162.                        (equivalent to "Component Disconnected").
  1163.  
  1164.          When the server receives any of the above responses, it
  1165.          should pass along the appropriate information to the host
  1166.          application.  The appopriate information is determined by
  1167.          whether the server represents an SNA or a non-SNA device.
  1168.  
  1169.          An SNA server should pass along a POSITIVE-RESPONSE from the
  1170.          client as a positive SNA Response Unit to the host
  1171.          application.  It should translate a NEGATIVE-RESPONSE from
  1172.          the client into an SNA negative Response Unit in which the
  1173.          Sense Data Indicator bit is on and which contains one of
  1174.          the following sense codes:
  1175.  
  1176.  
  1177.  
  1178.  
  1179. B. Kelly                 Expires January 1994                [Page 20]
  1180.  
  1181.  
  1182. Internet Draft           TN3270 Enhancements                 July 1993
  1183.  
  1184.  
  1185.              RESPONSE-FLAG        Equivalent        SNA Sense Code
  1186.              -------------        ----------        --------------
  1187.                  0x00           Command Reject        0x10030000
  1188.  
  1189.                  0x01        Intervention Required    0x08020000
  1190.  
  1191.                  0x02           Operation Check       0x10050000
  1192.  
  1193.                  0x03        Component Disconnected   0x08310000
  1194.  
  1195.          A non-SNA server should pass along a POSITIVE-RESPONSE from
  1196.          the client by setting the Device End Status bit on.  It
  1197.          should reflect a NEGATIVE-RESPONSE from the client by setting
  1198.          the Unit Check Status Bit on, and setting either the Command
  1199.          Reject, Intervention Required, or Operation Check Sense bit
  1200.          on when responding to the Sense command.
  1201.  
  1202.          In the case of Intervention Required or Component
  1203.          Disconnected being passed by the server to the host
  1204.          application, the host would normally refrain from sending any
  1205.          further data to the printer.  If and when the error condition
  1206.          at the client has been resolved, the client must send to the
  1207.          server a data message whose header DATA-TYPE field is set to
  1208.          REQUEST, and whose REQUEST-FLAG is set to ERR-COND-CLEARED.
  1209.          Note that this message has no data portion.  Upon receipt of
  1210.          this message, the server should pass along the appropriate
  1211.          information to the host application so that it may resume
  1212.          sending printer output.  Again, the form of this information
  1213.          depends on whether the server represents an SNA or a non-SNA
  1214.          device.
  1215.  
  1216.          An SNA server should reflect an ERR-COND-CLEARED to the host
  1217.          application by sending an SNA LUSTAT RU with one of the
  1218.          following sense codes:
  1219.  
  1220.           - if the previous error condition was an Intervention
  1221.             Required, the server should send sense code 0x00010000
  1222.  
  1223.           - if the previous error condition was Component
  1224.             Disconnected, the server should send sense code 0x082B0000
  1225.  
  1226.          A non-SNA server should set the corresponding bits in the
  1227.          Ending Status and Sense Condition bytes.
  1228.  
  1229.  
  1230. 11. The 3270 ATTN Key
  1231.  
  1232.    The 3270 ATTN key is interpreted by many host applications in an
  1233.    SNA environment as an indication that the user wishes to interrupt
  1234.    the execution of the current process.  The Telnet Interrupt Process
  1235.    (IP) command was defined expressly for such a purpose, so it seems
  1236.  
  1237.  
  1238. B. Kelly                 Expires January 1994                [Page 21]
  1239.  
  1240.  
  1241. Internet Draft           TN3270 Enhancements                 July 1993
  1242.  
  1243.  
  1244.    logical to use IP to implement support for the 3270 ATTN key.  This
  1245.    requires two things:
  1246.  
  1247.     - TN3270E clients should provide as part of their keyboard
  1248.       mapping a single key or a combination of keys that map to
  1249.       the 3270 ATTN key.  When the user presses this key(s), the
  1250.       client should transmit a Telnet IP command to the server.
  1251.  
  1252.     - TN3270E servers should translate the IP command received from
  1253.       a TN3270E client into the appropriate form and pass it along
  1254.       to the host application as an ATTN key.  In other words, the
  1255.       server representing an SLU in an SNA session should send
  1256.       a SIGNAL RU to the host application.
  1257.  
  1258.    The ATTN key is not supported in a non-SNA environment; therefore,
  1259.    a TN3270E server representing non-SNA 3270 devices should ignore
  1260.    any Telnet IP commands it receives from a client.
  1261.  
  1262. 12. The 3270 SYSREQ Key
  1263.  
  1264.    The 3270 SYSREQ key is useful in an SNA environment when the ATTN
  1265.    key is not sufficient to terminate a process.  While there are
  1266.    other uses for the SYSREQ key, and while its function is more
  1267.    complicated than what is dealt with in this document, it seems
  1268.    reasonable to implement a subset of the SYSREQ key support that
  1269.    would be beneficial to a large number of users.  This subset would
  1270.    be limited to support for the sequence of pressing SYSREQ and
  1271.    typing LOGOFF that many users employ to immediately terminate an
  1272.    SNA session.  It is recognized that in the case of host-resident
  1273.    TN3270E servers, essentially the same thing can be accomplished by
  1274.    the user unilaterally closing the Telnet connection, but in the
  1275.    case of servers that do not reside on the host (for example, the
  1276.    commercial TCP-to-SNA gateways) users may wish to terminate the SNA
  1277.    session without closing the Telnet connection.
  1278.  
  1279.    The Telnet Abort Output (AO) command seems the appropriate
  1280.    mechanism for implementing this limited SYSREQ key support, given
  1281.    that in a real SNA session, once the user presses the SYSREQ key,
  1282.    the host application is prevented from sending any more output to
  1283.    the terminal (unless the user presses SYSREQ a second time), but
  1284.    the user's process continues to execute.
  1285.  
  1286.    In order to implement SYSREQ key support, TN3270E clients should
  1287.    provide a key (or combination of keys) that is identified as
  1288.    mapping to the 3270 SYSREQ key.  When the user presses this key(s),
  1289.    the client should transmit a Telnet AO command to the server.
  1290.  
  1291.    Upon receipt of the AO command, the TN3270E server should enter
  1292.    what will be loosely termed "suspended mode" for the connection.
  1293.    Any attempt by the host application to send data to the client
  1294.    while the connection is "suspended" should be responded to by the
  1295.  
  1296.  
  1297. B. Kelly                 Expires January 1994                [Page 22]
  1298.  
  1299.  
  1300. Internet Draft           TN3270 Enhancements                 July 1993
  1301.  
  1302.  
  1303.    server with a negative response, sense code 0x082D, indicating an
  1304.    "LU Busy" condition.  The server should not transmit anything to
  1305.    the client on behalf of the host application.  While the connection
  1306.    is "suspended," any data messages (except responses) exchanged
  1307.    between the client and server should have the DATA-TYPE flag set to
  1308.    SCS-DATA and the RESPONSE-FLAG set to ALWAYS-RESPONSE.
  1309.  
  1310.    At this point, there are two possible courses of action on the part
  1311.    of the user:
  1312.  
  1313.     - transmit the string LOGOFF (upper or lower case), which will
  1314.       result in the server terminating the SNA session with the host
  1315.       application.  In the case of host-based servers, this will also
  1316.       have the effect of closing the Telnet connection.
  1317.  
  1318.     - press the "SYSREQ" key again, which will result in the
  1319.       transmission of another AO to the server.  The server should
  1320.       then send to the host application an LUSTAT RU with a value of
  1321.       0x082B indicating "presentation space integrity lost."  The
  1322.       server will then "un-suspend" the Telnet connection to the
  1323.       client, meaning it will allow the host application to once
  1324.       again send data to the client.
  1325.  
  1326.    If, while the Telnet connection is "suspended," the user transmits
  1327.    anything other than the above, the server should respond with the
  1328.    string "COMMAND UNRECOGNIZED" to the client.  The server should not
  1329.    send anything to the host application on behalf of the client.
  1330.  
  1331.    The SYSREQ key is not supported in a non-SNA environment; in fact,
  1332.    use of this key on a non-SNA 3270 terminal generally gets the user
  1333.    into difficulties.  Therefore, TN3270E servers representing non-SNA
  1334.    3270 terminals should ignore any Telnet AO commands they receive
  1335.    from a client.
  1336.  
  1337.  
  1338. 13. 3270 Structured Fields
  1339.  
  1340.    3270 structured fields provide a much wider range of features than
  1341.    "old-style" 3270 data, such as support for graphics, partitions and
  1342.    IPDS printer data streams. It would be unreasonable to expect all
  1343.    TN3270E clients to support all possible structured field functions,
  1344.    yet there must be a mechanism by which those clients that are
  1345.    capable of supporting some or all structured field functions can
  1346.    indicate their wishes.
  1347.  
  1348.    The design of 3270 structured fields provides a convenient means to
  1349.    convey the level of support (including no support) for the various
  1350.    structured field functions.  This mechanism is the Read Partition
  1351.    Query command, which is sent from the host application to the
  1352.    device.  The device responds with a Query Reply(s), listing which,
  1353.    if any, structured field functions it supports.
  1354.  
  1355.  
  1356. B. Kelly                 Expires January 1994                [Page 23]
  1357.  
  1358.  
  1359. Internet Draft           TN3270 Enhancements                 July 1993
  1360.  
  1361.  
  1362.    Therefore, all TN3270E clients must be able to respond to a Read
  1363.    Partition Query command, even if only to indicate that it supports
  1364.    no structured field functions.  Note that clients must support both
  1365.    the Read Partition Query (Type 02), and all forms of the Read
  1366.    Partition Query List (Type 03).
  1367.  
  1368.  
  1369. 14. Examples
  1370.  
  1371.    The following example shows a TN3270E-capable server and a
  1372.    traditional tn3270 client establishing a connection:
  1373.  
  1374.       Server:  IAC DO TN3270E
  1375.       Client:  IAC WON'T TN3270E
  1376.       Server:  IAC DO TERMINAL-TYPE
  1377.       Client:  IAC WILL TERMINAL-TYPE
  1378.       Server:  IAC SB TERMINAL-TYPE SEND IAC SE
  1379.       Client:  IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE
  1380.       Server:  IAC DO EOR IAC WILL EOR
  1381.       Client:  IAC WILL EOR IAC DO EOR
  1382.       Server:  IAC DO BINARY IAC WILL BINARY
  1383.       Client:  IAC WILL BINARY IAC DO BINARY
  1384.          (3270 data stream is exchanged)
  1385.  
  1386.    The following example shows a TN3270E-capable server and a
  1387.    TN3270E-capable client establishing a generic terminal session:
  1388.  
  1389.       Server:  IAC DO TN3270E
  1390.       Client:  IAC WILL TN3270E
  1391.       Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
  1392.       Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SE
  1393.       Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
  1394.                       anyterm IAC SE
  1395.       Client:  IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
  1396.       Server:  IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
  1397.          (3270 data stream is exchanged)
  1398.  
  1399.    The following example shows a TN3270E-capable server and a
  1400.    TN3270E-capable client establishing a terminal session where the
  1401.    client requests a specific device-name:
  1402.  
  1403.       Server:  IAC DO TN3270E
  1404.       Client:  IAC WILL TN3270E
  1405.       Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
  1406.       Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5
  1407.                       CONNECT myterm IAC SE
  1408.       Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5 CONNECT
  1409.                       myterm IAC SE
  1410.       Client:  IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
  1411.       Server:  IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
  1412.          (3270 data stream is exchanged)
  1413.  
  1414.  
  1415. B. Kelly                 Expires January 1994                [Page 24]
  1416.  
  1417.  
  1418. Internet Draft           TN3270 Enhancements                 July 1993
  1419.  
  1420.  
  1421.    The following example shows a TN3270E-capable server and a
  1422.    TN3270E-capable client attempting to establish a terminal session;
  1423.    multiple attempts are necessary because the device-name initially
  1424.    requested by the client is already in use:
  1425.  
  1426.       Server:  IAC DO TN3270E
  1427.       Client:  IAC WILL TN3270E
  1428.       Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
  1429.       Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5
  1430.                       CONNECT myterm IAC SE
  1431.       Server:  IAC SB TN3270E DEVICE-TYPE REJECT REASON
  1432.                       DEVICE-IN-USE IAC SE
  1433.       Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2
  1434.                       CONNECT herterm IAC SE
  1435.       Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
  1436.                       herterm IAC SE
  1437.       Client:  IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
  1438.       Server:  IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
  1439.          (3270 data stream is exchanged)
  1440.  
  1441.    The following example shows a TN3270E-capable server and a
  1442.    TN3270E-capable client establishing a printer session where the
  1443.    client requests a specific device-name, and where some amount
  1444.    of 3270 function negotiation is required before an agreement is
  1445.    reached:
  1446.  
  1447.       Server:  IAC DO TN3270E
  1448.       Client:  IAC WILL TN3270E
  1449.       Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
  1450.       Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1 CONNECT
  1451.                       myprt IAC SE
  1452.       Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT
  1453.                       myprt IAC SE
  1454.       Client:  IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC SE
  1455.       Server:  IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL
  1456.                       RESPONSES IAC SE
  1457.       Client:  IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC SE
  1458.       Server:  IAC SB TN3270E FUNCTIONS IS DATA-STREAM-CTL IAC SE
  1459.          (3270 data stream is exchanged)
  1460.  
  1461.    The following example shows a TN3270E-capable server and a
  1462.    TN3270E-capable client establishing first a generic terminal
  1463.    session, then a printer session where the "partner" printer for
  1464.    the assigned terminal is requested:
  1465.  
  1466.       Server:  IAC DO TN3270E
  1467.       Client:  IAC WILL TN3270E
  1468.       Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
  1469.       Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SE
  1470.       Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
  1471.                       termXYZ IAC SE
  1472.  
  1473.  
  1474. B. Kelly                 Expires January 1994                [Page 25]
  1475.  
  1476.  
  1477. Internet Draft           TN3270 Enhancements                 July 1993
  1478.  
  1479.  
  1480.       Client:  IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
  1481.       Server:  IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
  1482.          (3270 data stream is exchanged)
  1483.            .            .
  1484.            .            .
  1485.          (user decides to request a printer session,
  1486.           so client again connects to Telnet port on server)
  1487.       Server:  IAC DO TN3270E
  1488.       Client:  IAC WILL TN3270E
  1489.       Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
  1490.       Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1
  1491.                       ASSOCIATE termXYZ IAC SE
  1492.       Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT
  1493.                       termXYZ's-prt IAC SE
  1494.       Client:  IAC SB TN3270E FUNCTIONS REQUEST SCS-CTL-CODES
  1495.                       RESPONSES IAC SE
  1496.       Server:  IAC SB TN3270E FUNCTIONS IS SCS-CTL-CODES RESPONSES
  1497.                       IAC SE
  1498.          (3270 data stream is exchanged)
  1499.  
  1500.  
  1501. 15. References
  1502.  
  1503. [1] Rekhter, J., "Telnet 3270 Regime Option", RFC 1041, IBM
  1504.     Corporation, January 1988.
  1505.  
  1506. [2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091,
  1507.     FTP Software, Inc., February 1989.
  1508.  
  1509. [3] Postel, J., and J. Reynolds, "Telnet Binary Transmission",
  1510.     RFC 856, USC/Information Sciences Institute, May 1983.
  1511.  
  1512. [4] Postel, J., "Telnet End of Record Option", RFC 885, USC/
  1513.     Information Sciences Institute, December 1983.
  1514.  
  1515. [5] "3270 Information Display System - Data Stream Programmer's
  1516.     Reference", publication number GA24-0059, IBM Corporation.
  1517.  
  1518. [6] "Systems Network Architecture - Network Product Formats",
  1519.     publication number LY43-0081, IBM Corporation.
  1520.  
  1521. [7] "3174 Establishment Controller Functional Description",
  1522.     publication number GA23-0218, IBM Corporation.
  1523.  
  1524.  
  1525. 16. Author's Note
  1526.  
  1527.    Portions of this document were drawn from the following sources:
  1528.  
  1529.     - A White Paper written by Owen Reddecliffe, WRQ Corporation,
  1530.       October 1991.
  1531.  
  1532.  
  1533. B. Kelly                 Expires January 1994                [Page 26]
  1534.  
  1535.  
  1536. Internet Draft           TN3270 Enhancements                 July 1993
  1537.  
  1538.  
  1539.     - Experimental work on the part of Cleve Graves and Michelle
  1540.       Angel, OpenConnect Systems, 1992 - 1993.
  1541.  
  1542.     - Discussions at the March 1993 IETF meeting.
  1543.  
  1544.     - Discussions on the "TN3270E" list, Spring/Summer 1993.
  1545.  
  1546.  
  1547. 17. Author's Address
  1548.  
  1549.    Bill Kelly
  1550.    Division of University Computing
  1551.    144 Parker Hall
  1552.    Auburn, AL  36849
  1553.  
  1554.    Phone: (205) 844-4512
  1555.  
  1556.    Email: kellywh@mail.auburn.edu
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570.  
  1571.  
  1572.  
  1573.  
  1574.  
  1575.  
  1576.  
  1577.  
  1578.  
  1579.  
  1580.  
  1581.  
  1582.  
  1583.  
  1584.  
  1585.  
  1586.  
  1587.  
  1588.  
  1589.  
  1590.  
  1591.  
  1592. B. Kelly                 Expires January 1994                [Page 27]
  1593.  
  1594.  
  1595.  
  1596.